OpenEdge Getting Started:<br />Core Business Services Trusted domain registry

To configure external authentication systems for run time, you must configure OpenEdge with the authentication system type and domain information it requires to validate the login-session token (client-principal object) generated by the 4GL authentication system. This is accomplished by populating an internal storage object referred to as a trusted domain registry, or simply a registry. OpenEdge employs multiple registries in its architecture; each registry is capable of being independently configured to protect each Progress session and database connection.

You can combine all the registries together into a single, unified validation source so that no matter where you assert a client-principal object (in a database connection or a 4GL session) the validation is performed in the same place. You can also choose to load each registry independently so that a client-principal is validated at each point it is used. The method you choose will reflect the security architecture implemented in your 4GL application.

If you want the Progress session to validate client-principal objects at run time to establish a session-wide ID, you need to load the Progress session’s registry through methods provided in the SECURITY-POLICY object. These methods allow the application to load the session’s registry from a trusted OpenEdge database source or manually from any application-supplied source.

Each OpenEdge database also has one trusted database domain registry, which is loaded at run time from one of two sources. The registry can be loaded from its database’s tables, which are populated by using either Data Administration or the character Data Dictionary, or it can be loaded from the contents of the Progress session’s registry. The former load method is used when your application wants each OpenEdge database to have a unique configuration of authentication systems and domains for validating client-principal objects. The latter method is used when your application wants to use a single configuration of authentication system and domains that are used by the Progress session and all the OpenEdge database connections.

The interaction and sharing of registry information are controlled through options that are contained in an OpenEdge database and managed using either Data Administration or the character Data Dictionary.

Populating the registries

Any one registry can support any number of 4GL-supported authentication-type systems. The registry information that is loaded from database tables at run time includes only those authentication domains that are marked as enabled. This provides the flexibility to configure and support multiple types of authentication systems in the 4GL application and then simply enable or disable the appropriate one, or ones, at the production site.

Each database has only one registry, but the registry can have multiple domains.

Adding external authentication system domains, one at a time, by using the REGISTER-DOMAIN( ) method.

Adding one or more database domain registries by using the LOAD-DOMAINS( ) method.

Each registry entry loaded at run time represents a trust relationship, indicating that OpenEdge can trust the authenticated user IDs originating from that 4GL authentication system.

Once an application user ID or database connection ID is established by some registry domain entry, it can then be used for various kinds of authorization. The CAN-* permissions apply only to database connection IDs; with the CAN-DO permissions, it can be any ID that the application wants to use. There is no dependency on having a connection to the _User table.

Before the 4GL application can assert and validate the user ID, your 4GL authentication system procedure must first create the client-principal object. It then inserts the user ID, authentication-domain name, and login-session ID, among other things. When the client-principal object (the user ID) is fully populated, the object may then be sealed to indicate a successful user authentication or failed to indicate a failed user authentication. In both of these cases, the seal and fail methods automatically trigger user login-session auditing if it is enabled.